-- card: 5525 from stack: in
-- bmap block id: 0
-- flags: 0000
-- background id: 2619
-- name: The Basic Principles


-- part contents for background part 3
----- text -----

The Basic Principles

-- part contents for background part 2
----- text -----

There are three basic ground rules you must rememeber when designing stacks that will or may ultimately be used by people who wish to use HyperDA:

1.  Remember that users accessing a stack through HyperDA are always in
     browse mode.  That means they cannot alter information, add new 
     contents to fields, or otherwise change the stack’s contents.  This also 
     means that your scripts cannot change the contents of the stack.  The
     fundamental rule, then, is:  no command that alters stack contents will
     work in HyperDA.

2.  Visual effects are not visible when stacks are being browsed within 
     HyperDA.  Having visual effects present in your stacks will not, in and 
     of itself, make them incompatible with HyperDA; it’s just that users 
     will not see those effects.  If you are using the effects to convey content,
     you’ll find some loss of information in the translation if you don’t 
     think about this design issue in advance.

3.  Sound effects, other than the usual Macintosh “beep”  are not audible
     in HyperDA.

Beyond these limits -- and in partial explanation of some of them -- HyperDA supports a limited but powerful sub-set of the HyperTalk™ programming language commands built into HyperCard.

These principles -- browse-only stacks without visual or sound effects and a limited HyperTalk vocabulary support --mean, among other things, that stacks to be used with HyperDA should be content-centered rather than action-centered.  If the primary purpose of your stack is to transfer information to users, it is a prime candidate for HyperDA implementation and adaptation.  If, on the other hand, you are building a calculator-type stack that must generate and display new values, it won’t work under HyperDA at all.  In between, of course, are all manner of stacks that need more or less interaction.

For example, a typical address stack might at first glance appear to require the user to be able to enter new people into it and therefore not very useful under HyperDA.  But if the user is running his favorite word processor and needs to get the address of a client to copy and paste into the inside address of a letter, he can open the address stack using the HyperDA desk accessory, use the usual find methods to locate the desired address, and then copy it for pasting into the letter.  Similarly, if all he wants is the phone number of his accountant while he’s doing a spreadsheet for this year’s taxes, the ability to stay in the spreadsheet, open the address stack, find the account and call her, may prove quite valuable.

Another major class of stacks that lends itself to effective HyperDA implementations is help or training software.  If you are developing an accounting package and you want your user to be able to look up unfamiliar accounting terms or get  advice about how to post a cash receipt to three different categories of income, HyperDA is a good bet.  The user need not either have MultiFinder or a machine with more than 1 Megabyte of RAM to avoid having to close your application and open HyperCard just for this purpose.